Issue 1: Race condition in payment confirmation with collected data

ID: paymentviewmodel-collectdata-race-a3f2
File: sample/wallet/src/main/kotlin/com/reown/sample/wallet/ui/routes/dialog_routes/payment/PaymentViewModel.kt:347-353
Severity: MEDIUM
Category: code_quality

Context:

• Pattern: collectedValues map is accessed from executePayment() which can be triggered from multiple paths (direct payment, post-WebView, post-field collection)
• Risk: When user selects option without collectData, then later switches flows, stale data from previous sessions may be included
• Impact: Payment confirmation could send incorrect/stale user data to backend
• Trigger: Select option with IC → go back → select option without IC → confirm

Recommendation: Clear collectedValues when option selection changes, or scope collected data per optionId:

fun onOptionSelected(optionId: String) {
    val option = storedPaymentOptions.find { it.id == optionId } ?: return
    selectedOptionId = optionId
    
    // Clear stale collected data when changing options
    if (option.collectData == null) {
        collectedValues.clear()
    }
    
    val collectData = option.collectData
    // ...rest of logic
}

Issue 2: estimatedTxs coercion silently loses data

ID: mappers-eta-truncation-b7d1
File: product/pay/src/main/java/com/walletconnect/pay/Mappers.kt:58
Severity: LOW
Category: code_quality

Context:

• Pattern: Line 58 converts etaS (ULong) to Int with coerceAtMost(Int.MAX_VALUE.toULong().toLong()).toInt()
• Risk: Values exceeding Int.MAX_VALUE (2.1B seconds ≈ 68 years) are silently clamped
• Impact: Misleading UI if backend ever returns extremely large eta values
• Trigger: Backend returns etaS > 2147483647

Recommendation: Since field name is etaS (seconds) and values >68 years are unrealistic, add explicit null check instead:

estimatedTxs = option.etaS.let { eta ->
    if (eta <= Int.MAX_VALUE.toULong()) eta.toInt() else null
}

Issue 3: Unconstrained image URLs from payment response

ID: paymentroute-asyncimage-xss-4c9a
File: sample/wallet/src/main/kotlin/com/reown/sample/wallet/ui/routes/dialog_routes/payment/PaymentRoute.kt:477-503
Severity: LOW
Category: security

Context:

• Pattern: AsyncImage loads merchant icons and token icons from backend-provided URLs without validation
• Risk: Malicious URLs (e.g., javascript:, data:, file paths) could be injected if backend is compromised
• Impact: Coil library mitigates most XSS vectors, but no explicit URL scheme whitelist
• Trigger: Compromised backend or MITM attack modifying payment response

Recommendation: Validate icon URL schemes before loading:

@Composable
private fun MerchantIcon(paymentInfo: Wallet.Model.PaymentInfo?, size: Dp) {
    val iconUrl = paymentInfo?.merchant?.iconUrl?.takeIf { url ->
        url.startsWith("https://", ignoreCase = true) || url.startsWith("http://", ignoreCase = true)
    }
    iconUrl?.let { validUrl ->
        AsyncImage(model = validUrl, ...)
    } ?: run {
        // fallback placeholder
    }
}

Issue 1: New parameter added to PaymentOption data class constructor

ID: brk-pay-paymentoption-collectdata-field-a8c3
File: product/pay/src/main/java/com/walletconnect/pay/Pay.kt:40
Severity: LOW
Category: breaking_change

Context:

• Pattern: Data class constructor signature changed - new parameter collectData: CollectDataAction? = null added as 5th parameter to Pay.PaymentOption
• Risk: Consumers who construct PaymentOption instances using positional parameters will face compilation errors. Kotlin data class .copy() calls are backward compatible due to default value.
• Impact: Minimal - PaymentOption is typically returned by the SDK's getPaymentOptions() API, not constructed by consumers. Consumers who mock or test this class may need updates.
• Trigger: Compilation time for consumers who construct PaymentOption with positional parameters, or consumers using Java interop without named parameters.

Recommendation:

• Document in release notes that PaymentOption now includes per-option collectData
• Mark as minor version bump since the field has a default value and is unlikely to break typical usage
• Consider adding @JvmOverloads if Java consumers exist to maintain backward compatibility

Issue 2: New parameter added to Wallet.Model.PaymentOption data class constructor

ID: brk-wallet-paymentoption-collectdata-field-b2f7
File: product/walletkit/src/main/kotlin/com/reown/walletkit/client/Wallet.kt:530
Severity: LOW
Category: breaking_change

Context:

• Pattern: Data class constructor signature changed - new parameter collectData: CollectDataAction? = null added as 5th parameter to Wallet.Model.PaymentOption
• Risk: Same as Issue 1 - consumers constructing this class with positional parameters will face compilation errors.
• Impact: Minimal - Wallet.Model.PaymentOption is returned by WalletKit's payment APIs, not typically constructed by consumers. Mocking/testing code may need updates.
• Trigger: Compilation time for consumers who construct Wallet.Model.PaymentOption with positional parameters.

Recommendation:

• Document in release notes as part of the payment API enhancement
• Mark as minor version bump since default value maintains backward compatibility for named parameter usage
• Ensure sample app and integration tests demonstrate the new per-option collectData usage